Open
Visual Studio and create a new Game Studio 4.0 Windows Game project.
Notice that your main project includes two code files (program.cs and
game1.cs), and you have a content project you previously used. You can
safely ignore everything in program.cs because it is simply the stub
that launches the game. As a matter of fact, this isn’t even used on
Windows Phone 7.
The interesting things that are discussed in this chapter are in game1.cs. Notice first that the Game1 class that is created comes from the Game
object provided by Game Studio. The initial starting project gives you
everything you need to start creating a game. It has a spot for
initialization, a spot to load the content your game needs, a spot to
update the game state, and a spot to render everything.
More things happen behind the
scenes than you are probably aware of, however. Start with the first
thing you see in the constructor, creating the GraphicsDeviceManager.
graphics = new GraphicsDeviceManager(this);
This one line of code starts a chain reaction of operations. It naturally creates a new GraphicsDeviceManager (which is discussed in just a moment), but it does more than that. This object implements IGraphicsDeviceService and IGraphicsDeviceManager. When you create the object, it takes the game parameter you’ve passed in (that is, the this parameter) and adds itself to the Services property of the game object.
Note
You can create and add your
own services to this property (it maintains a list of services), and it
is a convenient way to get game-specific services directly from the
game rather than passing them around everywhere.
After the graphics device
manager has been added to the services list, the actual graphics device
is created when the constructor has finished executing. The default
options work just fine, but you actually do have some control over the
settings the device has.
Notice that quite a few
different properties on this object can be used to control how the
device is created or to get information about it. The first one is the GraphicsDevice.
Right now, it hasn’t been created yet, but after it has been, it can be
accessed here. You most likely never need it, though, because the GraphicsDevice is a property of the Game itself.
The GraphicsProfile is another property you can access. Next is the IsFullScreen
property that behaves differently depending on the platform you run.
The default value here is false, although on Xbox 360, it doesn’t
matter what this is set as because you are always full screen on that
platform. On Windows, setting this to true causes the device to be
created in what is called full screen exclusive mode, and your
rendering encompasses the entire screen. On Windows Phone 7, this
controls whether the system tray bar is visible or not visible.
Note
Taking over the full screen in
exclusive mode on Windows is not a nice thing to do without the user
asking you to do so. In modern operating systems, the graphics hardware
is shared nicely between games and the operating system, and forcing
the operating system to yield to your game can cause behavior that some
of your players may very well find annoying (the authors here included).
The next set of properties is
the most commonly changed, and it includes the preferences. Because
they are preferences and not requirements, the runtime attempts to use
these settings, and if it cannot use them, it falls back to what it
feels is the closest to what you requested. These properties are PreferMultisampling, PreferredBackBufferWidth, PreferBackBufferHeight, PreferBackBufferFormat, and PreferDepthStencilFormat.
The back buffer is where your
content is rendered, and the sizes in these preferences (width and
height), control how large that area is. On Windows, in nonfull screen
mode, this also controls the size of the window. In full screen mode,
it controls the resolution of the monitor when it takes exclusive
control of it. On Xbox 360 and Windows Phone 7, the devices have a
built-in native resolution. For Windows Phone 7, the device has a
resolution of 480×800 (in portrait mode), whereas the Xbox is
configurable. On each of these platforms, if you ask for a different
back buffer resolution, it is scaled to the native device resolution.
Multisampling is the
process used to remove what are called the “jaggies” from rendered
images. These jagged edges are formed normally on the edges of objects
or on lines that are not on pixel boundaries (for example,
nonhorizontal or vertical lines). Multisampling blends each pixel with
other pixels around it to help soften these jagged edges. It does this
by rendering the image larger and blending multiple pixels down to a
single pixel. Although it doesn’t necessarily remove the jagged edges,
it certainly can help. There is a performance cost for doing this, so
this defaults to false.
The last two preferences are
the formats for the back buffer and the depth stencil. Formats are used
to describe how data is laid out for the final rendered image. For the
back buffer, this is how the color is laid out, and the default for
this is actually SurfaceFormat.Color.
This is a 32-bit format that has 8 bits for red, green, blue, and
alpha. The depth stencil buffer formats control how many bits are used
for the depth buffer and stencil buffer.
The last two properties are SupportedOrientations, which is mainly used for Windows Phone 7, and SynchronizeWithVerticalRetrace.
Synchronizing with the vertical retrace is a way to prevent tearing by
pausing until the device is ready to render the entire screen at once.
There are also six different events you can hook off of the graphics object, most of which are self-explanatory based on the names. The one interesting one is PreparingDeviceSettings.
This event is triggered right before the device is created, and it
gives you the opportunity to override any of the settings before the
device is actually created. Use this only if you know the device
supports the settings you request.
There are also two methods on the object, ApplyChanges which attempts to instantly update the device to the current settings (or create a new device if required), and ToggleFullscreen,
which makes a windowed game full screen and a full screen game windowed
during runtime. Using either of these is rarely required.
The last thing the
constructor does is set the root directory of the automatically created
content manager to “Content,” which is where your content project
places the content you add to your game. The content manager is created
for you when the game is created, so you can begin using it
immediately.
Content.RootDirectory = "Content";
The default template has overrides for five common methods: Initialize, LoadContent, UnloadContent, Update, and Draw. Although nothing happens in Initialize and UnloadContent, the other three have basic stub code. The LoadContent method creates the sprite batch object you almost certainly need. The Draw method clears the screen to the infamous CornflowerBlue color. Finally, the Update
method adds a quick check to see if you’re pressing the Back button on
your controller to see if it should exit the game. We get into the flow
of these methods and how they’re used in just a moment, but first,
let’s take a look at the Game class itself.
Note
For Windows Phone 7 projects,
there is another very important aspect to the game lifetime you need to
understand called “Tombstoning”.
